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STATEMENT  OF  INTENT 


The  Consultative  Committee  for  Space  Data  Systems  (CCSDS)  is  an  organization  officially 
established  by  the  management  of  member  space  Agencies.  The  Committee  meets 
periodically  to  address  data  systems  problems  that  are  common  to  all  participants,  and  to 
formulate  sound  technical  solutions  to  these  problems.  Inasmuch  as  participation  in  the 
CCSDS  is  completely  voluntary,  the  results  of  Committee  actions  are  termed 
Recommendations  and  are  not  considered  binding  on  any  Agency. 

This  Recommendation  is  issued  by,  and  represents  the  consensus  of,  the  CCSDS  Plenary 
body.  Agency  endorsement  of  this  Recommendation  is  entirely  voluntary.  Endorsement, 
however,  indicates  the  following  understandings: 

o  Whenever  an  Agency  establishes  a  CCSDS-related  standard,  this  standard  will  be  in 
accord  with  the  relevant  Recommendation.  Establishing  such  a  standard  does  not 
preclude  other  provisions  which  an  Agency  may  develop. 

o  Whenever  an  Agency  establishes  a  CCSDS-related  standard,  the  Agency  will  provide 
other  CCSDS  member  Agencies  with  the  following  information: 

The  standard  itself. 

The  anticipated  date  of  initial  operational  capability. 

The  anticipated  duration  of  operational  service. 

o  Specific  service  arrangements  shall  be  made  via  memoranda  of  agreement.  Neither  this 
Recommendation  nor  any  ensuing  standard  is  a  substitute  for  a  memorandum  of 
agreement. 

No  later  than  five  years  from  its  date  of  issuance,  this  Recommendation  will  be  reviewed  by 
the  CCSDS  to  determine  whether  it  should:  (1)  remain  in  effect  without  change;  (2)  be 
changed  to  reflect  the  impact  of  new  technologies,  new  requirements,  or  new  directions;  or, 
(3)  be  retired  or  canceled. 

In  those  instances  when  a  new  version  of  a  Recommendation  is  issued,  existing  CCSDS- 
related  Agency  standards  and  implementations  are  not  negated  or  deemed  to  be  non-CCSDS 
compatible.  It  is  the  responsibility  of  each  Agency  to  determine  when  such  standards  or 
implementations  are  to  be  modified.  Each  Agency  is,  however,  strongly  encouraged  to  direct 
planning  for  its  new  standards  and  implementations  towards  the  later  version  of  the 
Recommendation. 
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FOREWORD 


This  document,  which  is  a  technical  Recommendation  prepared  by  the  Consultative 
Committee  for  Space  Data  Systems  (CCSDS),  is  intended  for  use  by  participating  space 
Agencies  in  their  development  of  space  telecommand  systems. 

This  Recommendation  allows  the  implementing  organizations  within  each  Agency  to 
proceed  coherently  with  the  development  of  compatible  Standards  for  the  flight  and  ground 
systems  that  are  within  their  cognizance.  Agency  Standards  derived  from  this 
Recommendation  may  implement  only  a  subset  of  the  optional  features  allowed  herein,  or 
may  incorporate  features  not  addressed  by  the  Reconunendation. 

In  order  to  establish  a  common  framework  within  which  the  Agencies  may  develop 
standardized  telecommand  services,  the  CCSDS  advocates  adoption  of  a  layered  systems 
architecture.  Within  this  approach,  specific  layers  of  service  (including  their  operational 
protocol  and  data  structuring  techniques)  may  be  selected  for  implementation  according  to 
mission  requirements. 

The  current  layered  set  of  CCSDS  telecommand  Recommendations  was  developed  to  match 
the  conventional  free-flying  mission  environment,  as  characterized  by  the  transmission  of 
command  data  at  relatively  low  uplink  data  rates  to  spacecraft  of  moderate  complexity.  The 
CCSDS  is  currently  examining  the  extension  of  these  Recommendations  (perhaps  by 
defining  expanded  protocols  and  data  structures  within  some  of  the  layers)  to  a  more  complex 
mission  environment,  including  the  transmission  of  multiple  data  types  at  very  high  data  rates 
to  space  vehicles  which  include  extensive  onboard  data  networking  capability. 

This  Recommendation  for  Telecommand  Channel  Service  was  developed  within  the  layered 
architectural  framework,  and  embraces  the  standard  data  structures  and  data  communication 
procedures  which  may  be  used  by  conventional  missions  within  the  lowest  telecommand 
system  layers. 

Through  the  process  of  normal  evolution,  it  is  expected  that  expansion,  deletion  or 
modification  to  this  document  may  occur.  This  Recommendation  is  therefore  subject  to 
CCSDS  document  management  and  change  control  procedures  which  are  defined  in 
Reference  [1]. 
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At  time  of  publication,  the  active  Member  and  Observer  Agencies  of  the  CCSDS  were 
Member  Agencies 

-  British  National  Space  Centre  (BNSC)/United  Kingdom. 

-  Canadian  Space  Agency  (CSA)/Canada. 
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-  European  Space  Agency  (ESA)/Europe. 
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-  National  Aeronautics  and  Space  Administration  (NASA  HQ)/USA. 
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-  Danish  Space  Research  Institute  (DSRI)/Denmark. 
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-  Hellenic  National  Space  Committee  (HNSC)/Greece. 

-  Indian  Space  Research  Organization  (ISRO)/India. 

-  Industry  Canada/Communications  Research  Centre  (CRC)/Canada. 

-  Institute  of  Space  and  Astronautical  Science  (ISAS)/Japan. 

-  Institute  of  Space  Research  (IKI)/Russian  Federation. 

-  KFKI  Research  Institute  for  Particle  &  Nuclear  Physics  (KFKI)/Hungary. 

-  MIKOMTEK:  CSIR  (CSIR)/Republic  of  South  Africa. 

-  Ministry  of  Communications  (MOC)/Israel. 

-  National  Oceanic  &  Atmospheric  Administration  (NOAA)/USA. 

-  National  Space  Program  Office  (NSPO)/Taiwan. 

-  Swedish  Space  Corporation  (SSC)/Sweden. 

-  United  States  Geological  Survey  (USGS)/USA. 
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1  INTRODUCTION 

1.1  PURPOSE  AND  SCOPE 

The  purpose  of  this  document  is  to  establish  a  common  Recommendation  which  defines  the 
systems  architecture  of  a  spacecraft  telecommand  “Channel  Service”.  The  intent  of  this 
architecture  is  to  provide  a  conunon  framework  within  which  the  Agencies  participating  in 
the  Consultative  Committee  for  Space  Data  Systems  (CCSDS)  may  implement  compatible 
future  spacecraft  telecommanding  systems. 

This  Recommendation  primarily  addresses  the  data  unit  formats  and  functions  which  are 
implemented  within  the  Coding  layer  and  the  Physical  layer  of  the  CCSDS  telecommand 
Channel  Service.  THE  ASSOCIATED  DETAILED  OPERATIONAL  PROTOCOLS 
WHICH  OPERATE  ACROSS  THESE  LAYERS,  AND  THE  FLOW  OF  CONTROL 
INFORMATION  REQUIRED  TO  INITIALIZE  THE  LAYERS  AND  DIRECT  THE 
TRANSFER  OF  DATA  BETWEEN  THEM,  ARE  NOT  PRESENTLY  ADDRESSED 
WITHIN  THIS  DOCUMENT:  THESE  REMAIN  ITEMS  FOR  POTENTIAL 
EXTENSION  OF  THIS  RECOMMENDATION 

The  operating  principles  and  procedures  for  the  CCSDS  are  defined  in  Reference  [1].  The 
context  of  the  Channel  Service  within  the  overall  Telecommand  System  is  described  in 
Reference  [2].  This  is  a  working  document,  subject  to  update  as  experience  is  gained,  which 
provides  an  inter-Agency  coordination  mechanism  that  ensures  that  compatible 
implementations  are  facilitated. 


1.2  APPLICABILITY 

This  Recommendation  serves  as  a  guideline  for  the  development  of  compatible  internal 
Agency  standards  in  the  field  of  spacecraft  commanding.  This  Recommendation  is  not 
retroactive,  nor  does  it  commit  any  Agency  to  implement  the  recommended  telecommand 
concepts  at  any  future  time.  Nevertheless,  all  CCSDS  Agencies  accept  the  principle  that  all 
future  implementations  of  telecommand  which  are  used  in  cross-support  situations  will  be 
based  on  this  Recommendation. 

The  CCSDS  has  developed  a  layered  concept  for  spacecraft  teleconunanding,  which  is  fully 
described  in  Reference  [2].  Standard  services  are  defined  within  each  layer,  and  Agencies 
will  be  encouraged  to  develop  corresponding  facilities  to  provide  these  services  in  support  of 
Projects.  To  be  fully  compatible  with  the  CCSDS  concept,  a  Project’s  telecommanding 
architecture  should  follow  this  Recommendation  for  Channel  Service,  plus  the 
Recommendations  for  telecommand  “Data  Management  Service”  and  telecommand  “Data 
Routing  Service”  which  are  described  in  References  [3]  and  [4],  respectively.  Projects  may 
also  elect  to  be  partially  compatible  with  the  concept  by  interfacing  with  the  standard  systems 
at  intermediate  layers  within  any  of  the  service  specifications. 
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1.3  BIT  NUMBERING  CONVENTION  AND  NOMENCLATURE 

In  this  document,  the  following  convention  is  used  to  identify  each  bit  in  an  N-bit  field.  The 
first  bit  in  the  field  to  be  transmitted  (i.e.,  the  most  left  justified  when  drawing  a  figure)  is 
defined  to  be  “Bit  0”;  the  following  bit  is  defined  to  be  “Bit  1”  and  so  on  up  to  “Bit  N-l”. 
When  the  field  is  used  to  express  a  binary  value  (such  as  a  counter),  the  Most  Signifieant  Bit 
(MSB)  shall  be  the  first  transmitted  bit  of  the  field,  i.e.,  “Bit  0”. 


BITO  BITN-1 


N-BIT  DATA  FIELD 


FIRST  BIT  TRANSMITTED  =  MSB 


In  accordance  with  modem  data  communications  practice,  spacecraft  data  fields  are  often 
grouped  into  8-bit  “words”  which  conform  to  the  above  convention.  Throughout  this 
Recommendation,  the  following  nomenclature  is  used  to  describe  this  grouping: 


8-BIT  WORD  =  “OCTET” 


By  CCSDS  convention,  all  “spare”  bits  shall  be  permanently  set  to  value  zero. 

Note  that  throughout  this  document,  the  word  “Telecommand”  may  be  abbreviated  as  “TC”. 


1.4  REFERENCES 

The  following  documents  are  referenced  in  the  text  of  this  Recommendation.  At  the  time  of 
publication,  the  editions  indicated  were  valid.  All  documents  are  subject  to  revision,  and 
users  of  this  Recommendation  are  encouraged  to  investigate  the  possibility  of  applying  the 
most  recent  editions  of  the  documents  indicated  below.  The  CCSDS  Secretariat  maintains  a 
register  of  currently  valid  CCSDS  Recommendations. 

[1]  Procedures  Manual  for  the  Consultative  Committee  for  Space  Data  Systems.  CCSDS 
AOO.O-Y-6.  Yellow  Book.  Issue  6.  Washington,  D.C.:  CCSDS,  May  1994. 
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[2]  Telecommand:  Summary  of  Concept  and  Rationale.  Report  Concerning  Space  Data 
Systems  Standards,  CCSDS  200.0-G-6.  Green  Book.  Issue  6.  Washington,  D.C.: 
CCSDS,  January  1987. 

[3]  Telecommand  Part  3  —  Data  Management  Service.  Recommendation  for  Space  Data 
Systems  Standards,  CCSDS  203.0-B-l.  Blue  Book.  Issue  1.  Washington,  D.C.: 
CCSDS,  January  1987. 

[4]  Telecommand  Part  2  —  Data  Routing  Service.  Recommendation  for  Space  Data 
Systems  Standards,  CCSDS  202.0-B-2.  Blue  Book.  Issue  2.  Washington,  D.C.: 
CCSDS,  November  1992. 

[5]  Radio  Frequency  and  Modulation  Systems — Part  1:  Earth  Stations  and  Spacecraft. 
Recommendation  for  Space  Data  Systems  Standards,  CCSDS  401. 0-B.  Blue  Book. 
Washington,  D.C.:  CCSDS,  May  1996. 


The  latest  issues  of  these  documents  may  be  obtained  from  the  CCSDS  Secretariat  at  the 
address  indicated  on  page  i. 
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2  TELECOMMAND  CHANNEL  SERVICE  OVERVIEW 


A  complete  summary  of  the  terminology  which  is  used  internal  to  this  document  is  presented 
in  Annex  A. 

The  TC  Channel  Service  (see  Figure  2-1)  enables  an  error-controlled  data  path  to  be 
established  for  the  transfer  of  telecommands  to  the  spacecraft.  The  service  contains  two 
distinct  layers  of  data  handling  operations: 

(1)  A  CODING  LAYER,  which  permits  teleconunand  information  bits  to  be  more 
reliably  transmitted  through  the  noisy  physical  data  channel  using  standard 
channel  coding  techniques.  The  Coding  layer  also  provides  information  about  the 
beginning  of  the  contents  of  valid  codeblocks  and  the  continuity  of  the  data 
stream,  and  it  delivers  the  contents  of  those  codeblocks  to  the  layer  above. 

(2)  A  PHYSICAL  LAYER,  which  contains  the  radio  frequency  and  modulation 
capabilities  that  may  be  invoked  to  establish  the  physical  data  channel:  these 
capabilities  are  fully  described  in  Reference  [5]  and  are  only  addressed  within  this 
document  as  required  for  clarity.  The  Physical  layer  also  contains  PHYSICAL 
LAYER  OPERATIONS  PROCEDURES  (PLOPs)  which  provide  the  methods 
of  activating  and  deactivating  the  physical  channel. 

A  complete,  detailed  specification  of  the  services  provided  by  each  layer  within  the  Channel 
Service  is  presented  in  Annex  B.  The  first-time  reader  should  digest  Annex  B  before 
proceeding  further  in  this  document. 

NOTES 

1  Figure  2-1  represents  a  logical  view  of  the  TC  System  and  physical  implementations 
may  not  necessarily  correspond  to  the  flow  of  operations  implied  by  the  figure. 

2  This  Recommendation  primarily  specifies  the  data  structures  and  procedures  flowing 
ACROSS  the  layers  from  the  sending  to  the  receiving  end  of  the  TC  System,  since 
these  have  a  direct  impact  on  the  long  lead-time  design  of  future  spacecraft  hardware 
and  software.  Comprehensive  definition  of  the  associated  operational  protocols 
within  each  layer  and  the  control  instructions,  which  are  required  to  initialize  the 
layers  and  to  direct  the  flow  of  TC  data  units  BETWEEN  the  layers,  remain  items  for 
potential  future  extension  of  this  document. 
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TELECOMMAND, 

PARTS:  DATA 
MANAGEMENT  SERVICE 


TELECOMMAND, 
PART  2:  DATA 
ROUTING  SERVICE 


TELECOMMAND, 
PARTI:  CHANNEL 
SERVICE 


Figure  2-1:  Telecommand  System 
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3  CODING  LAYER:  STANDARD  DATA  STRUCTURES  AND 
PROCEDURES 

3.1  OVERVIEW  OF  THE  CODING  LAYER 

The  Coding  layer  establishes  the  reliable,  error-controlled  data  channel  through  which  user 
telecommand  data  bits  may  be  transferred.  The  data  are  encoded  to  reduce  the  effects  of 
noise  in  the  Physical  layer  channel  on  the  user  data.  A  block  code  has  been  chosen  to 
provide  this  protection.  Synchronization  for  the  codeblock  and  delimiting  of  the  beginning 
of  user  data  are  provided  by  the  Command  Link  Transmission  Unit  (CLTU)  data  structure. 

Resolution  of  data  ambiguity  (sense  of  “1”  and  “0”)  when  receiving  the  symbol  stream  shall 
be  a  service  of  the  Coding  layer.  Data  ambiguity  may  result  from  the  modulation  technique 
utilized  in  the  Physical  layer  such  as  suppressed-carrier  modulation.  Ambiguity  resolution 
techniques  shall  use  inherent  information  in  the  symbol  stream  such  as  either  the  CLTU  start 
sequence  pattern  or  NRZ-M  modulation. 

Standard  procedures  for  randomizing,  encoding,  and  handling  fill  bits  are  described  in  3.3. 


3.2  STANDARD  DATA  STRUCTURES  WITHIN  THE  CODING  LAYER 
The  standard  data  structures  within  the  Coding  layer  are  the  TC  Codeblock  and  the  CLTU. 
3.2.1  TC  CODEBLOCK  FORMAT 


The  TC  Codeblock  format  is  a  fixed-length  data  entity  shown  in  Figure  3-1.  The  codeblock 
is  formulated  using  a  systematic  coding  technique  which  contains  N  information  bits  in  the 
leading  octets  and  the  error  control  in  the  last  octet.  The  TC  Codeblock  contains  an  integer 
number  of  octets  with  a  maximum  overall  length  of  8  octets  (64  bits). 


- “L”  CODEBLOCK  LENGTH - ► 

- INFORMATION - - ERROR  CONTROL - ► 


•  'N-1 

Pq.  Pp  •  •  •  Pe 

•^0 

“N”  TC  DATA  BITS  (may  be  randomized) 

(N  =  32,  40,  48,  OR  56) 

7  PARITY 
CHECK  BITS 

APPENDED 
FILLER  BIT 

Figure  3-1:  Telecommand  Codeblock  Format 
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Within  any  given  mission,  the  overall  length  “L”  of  the  TC  Codeblock  shall  be  fixed  and 
shall  be  selected  from  the  following  standard  lengths: 

L  =  40  bits  (N=32) 

L  =  48  bits  (N=40) 

L  =  56  bits  (N=48) 

L  =  64  bits  (N=56) 

The  preferred  length  is  L  =  64  bits. 

The  COMPLEMENTS  of  the  seven  parity  check  bits,  Pq  through  P6,  are  located  in  the  first 
seven  bits  of  the  last  octet  of  the  TC  Codeblock.  The  complements  are  used  to  aid  in 
maintaining  bit  synchronization  and  detection  of  bit  slippage.  The  encoding  procedure  for 
generating  these  parity  bits  is  described  in  3.3.2. 

The  last  bit  of  the  last  octet,  Fq,  is  a  filler  bit  appended  to  provide  an  overall  Codeblock 
length  which  is  an  integer  number  of  octets.  This  Filler  Bit  shall  always  be  a  zero. 


3.2.2  COMMAND  LINK  TRANSMISSION  UNIT  (CLTU)  FORMAT 

The  CLTU  is  the  data  structure  which  carries  the  TC  data  as  a  contiguous  series  of  encoded 
TC  Codeblocks  across  the  Channel  Service.  The  encoded  TC  data  within  the  CLTU  consist 
of  Input  Data  from  the  layer  above.  The  CLTU  has  the  structural  components  shown  in 
Figure  3-2. 


^ - COMMAND  LINK  TRANSMISSION  UNIT - ► 


START 

ENCODED 

TAIL 

SEQUENCE 

TC  DATA 

SEQUENCE 

TC  CODEBLOCKS 


LENGTH  OF 
ONETC 
CODEBLOCK 


Figure  3-2:  Components  of  the  CLTU 
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3.2.2.1  CLTU  Start  Sequence.  The  CLTU  Start  Sequence  field  delimits  the  start  of  the 
encoded  TC  data  within  the  CLTU.  It  consists  of  a  16-bit  synchronization  pattern  with  low 
autocorrelation  sidelobes  and  shall  have  the  following  pattern: 

1110101110010000 

I  i 

BITO  BIT  15 


3.2.2.2  Encoded  TC  Data.  The  Encoded  TC  Data  field  consists  of  a  set  of  TC 
Codeblocks  which  have  been  encoded  in  accordance  with  the  TC  Codeblock  encoding 
procedure.  In  addition  to  error  control  bits,  these  codeblocks  contain  the  Input  Data  to  this 
layer,  plus  any  fill  bits  that  were  appended  to  meet  codeblock  length  constraints.  The 
encoded  TC  data  field  may  have  been  randomized  before  encoding,  or  not  randomized,  as 
selected  for  the  mission.  (For  brevity,  “random”  is  used  in  place  of  “pseudo-random” 
throughout  this  document.  See  Annex  A.) 

3.2.2.3  Tail  Sequence.  The  CLTU  Tail  Sequence  field  is  a  data  structure  which  is 
constructed  specifically  to  be  a  noncorrectable  sequence  which  delimits  the  end  of  a  CLTU 
by  stopping  the  decoding  process.  The  Tail  Sequence  shall  have  the  same  length  as  the  TC 
Codeblocks  that  are  being  used.  The  Tail  Sequence  ^  shall  consist  of  leading  octets  having 
the  pattern  11000101,  repeated  as  necessary  until  the  next-to-last  octet  of  the  tail  sequence 
field  is  reached.  The  last  octet  completes  the  tail  sequence  field,  and  always  has  the  pattern 
01111001.  Therefore,  the  octet  pattern  for  the  standard  codeblock  lengths  may  be  described 
as  follows: 

Codeblock 

Length  L.  in  Bits  Tail  Sequence  Pattern 

40  11000101  11000101  11000101  11000101  01111001 
48  1 1000101  1 1000101  1 1000101  1 1000101  1 1000101  01 1 1 1001 
56  11000101  11000101  11000101  11000101  11000101  11000101  01111001 
64  11000101  11000101  11000101  11000101  11000101  11000101  11000101  01111001 


3.3  STANDARD  PROCEDURES  WITHIN  THE  CODING  LAYER 

The  following  subsections  define  the  procedures  for  randomization  of  Input  Data  and  coding 
of  TC  Codeblocks. 


1  A  pattern  of  alternating  “zeros”  and  “ones”  identical  to  the  idle  sequence  throughout  the 
length  of  a  codeblock  was  defined  in  the  previous  issue.  The  new  pattern  is  preferred  for 
new  designs  because  of  its  improved  performance.  See  Reference  [2]. 
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3.3.1  RANDOMIZATION  PROCEDURE 

In  order  to  maintain  bit  (or  symbol)  synchronization  with  the  received  telecommand  signal, 
the  incoming  signal  must  have  a  minimum  bit  transition  density  (see  Recommendation  2.2.3 
in  Reference  [5]). 

If  a  sufficient  bit  transition  density  is  not  ensured  for  the  channel  by  other  methods  (e.g.,  by 
use  of  certain  modulation  techniques  or  data  that  is  phase-coherent  with  the  subcarrier)  then 
the  randomizer  defined  in  this  subsection  is  required.  Its  use  is  optional  otherwise. 

The  presence  or  absence  of  randomization  is  fixed  for  a  physical  channel  and  is  managed 
(i.e.,  its  presence  or  absence  is  not  signaled  but  must  be  known  a  priori  by  the  spacecraft  and 
ground  system).  A  random  sequence  is  exclusively  ORed  with  the  Input  Data  to  increase 
the  frequency  of  bit  transitions.  On  the  receiving  end,  the  same  random  sequence  is 
exclusively  ORed  with  the  decoded  data,  restoring  the  original  data  form.  The  random 
sequence  is  generated  by  the  Bit  Transition  Generator  (BTG). 

3.3.1.1  Random  Sequence.  The  random  sequence  shall  be  generated  using  the 
following  polynomial: 


h(x)  =  x^  +  x6  +  x4  +  x3  +  x2  +  X  +  1 

This  sequence  repeats  after  255  bits,  continuing  as  needed.  The  first  40  bits  of  the 
sequence  are 

nil  nil  0011  1001  looi  iiio  oioi  loio  ono  looo 

Increasing  Time - > 


Figure  3-3  is  a  basic  logical  diagram  of  the  BTG. 


Initialize  to  an  “all  ones”  state. 


=  Modulo-2  adder 
(Exclusive-OR) 


Single  Bit  Delay 


Figure  3-3:  Bit  Transition  Generator  Logic  Diagram 
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3.3.1.2  APPLICATION  OF  THE  RANDOMIZER.  The  randomization  is  applied  at  the 
transmitting  end,  only  to  the  Input  Data.  The  BTG  is  preset  to  the  “all-ones”  state  and  then  is 
exclusively  ORed,  bit  by  bit,  with  the  Input  Data  until  the  process  ends  with  the  last  bit  of  the 
Input  Data.  The  randomization  may  also  be  applied  to  the  fill  bits  added  after  the  end  of  the 
Input  Data  to  complete  the  last  codeblock  of  the  CLTU,  but  this  is  optional. 

At  the  receiving  end,  the  derandomization  is  applied  to  the  successfully  decoded  TC  data. 
The  BTG  remains  in  the  “all-ones”  state  until  the  CLTU  Start  Sequence  has  been  detected. 
The  BTG  pattern  is  exclusively  ORed,  bit  by  bit,  to  the  successfully  decoded  data  (after  the 
Error  Control  Bits  have  been  removed).  The  BTG  is  reset  to  the  “all-ones”  state  following  a 
failure  of  the  decoder  to  successfully  decode  a  TC  codeblock  or  other  loss  of  TC  data. 


3.3.2  TC  CODEBLOCK  ENCODING  PROCEDURE 

A  systematic  block  coding  procedure  is  used  which  always  generates  7  parity  check  bits  per 
codeblock  and  which  is  always  computed  from  56  information  bits.  The  parity  check  bits  are 
then  COMPLEMENTED  and  placed  into  the  codeblock  as  shown  in  Figure  3-1. 

The  code  used  is  a  (63,56)  modified  Bose-Chaudhuri-Hocquenghem  (BCH)  code  which  uses 
the  following  generator  polynomial  to  produce  the  seven  parity  bits: 

g(x)  =  x’^  +  x^  +  x^  +  1 

It  may  be  desired  to  shorten  the  transmitted  codeblocks.  This  is  accomplished  by  reducing 
the  number  of  TC  data  bits  contained  within  the  transmitted  codeblocks.  To  maintain  octet 
boundaries  and  reasonable  efficiency,  32, 40,  and  48  bits  are  the  only  shortened  TC  data  field 
sizes  permitted. 

The  same  encoding  algorithm  shown  above  for  56  information  bits  also  serves  for  the 
shortened  cases  by  forcing  the  coding  algorithm  to  continue  to  operate  on  56-bit  fields.  The 
difference  between  the  shortened  TC  data  field  and  the  56  bits  is  treated  by  the  encoder  as 
“virtual  fill”  (zeros)  preceding  the  TC  data.  These  leading  zeros  are  NOT  outputted  from  the 
encoder,  nor  transmitted.  In  all  cases  the  overall  codeblock  length  is  always  8  bits  longer 
than  the  TC  data  field.  It  should  be  noted  that  this  “virtual  fill”  is  separate  and  distinct  from 
the  fill  of  3.3.3  which  is  used  when  there  is  insufficient  Input  Data  to  exactly  fit  the  last 
codeblock. 

The  code  generator  implementation  is  shown  in  Figure  3-4.  Note  that  the  shift  registers  are 
initialized  to  zero.  The  ganged  switch  is  in  position  1  while  the  N  TC  data  bits  are  being 
transmitted,  in  position  2  for  the  seven  parity  bits,  and  in  position  3  for  the  appended  fill  bit. 
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-PARITY  BITS- 


Figure  3-4:  (63,56)  Modified  BCH  Code  Generator 


3.3.3  FILL  BITS 

If  the  Input  Data  do  not  fit  exactly  within  an  integral  number  of  TC  Codeblocks,  the  last 
octet(s)  and  ONLY  the  last  octet(s)  of  the  information  field  of  the  last  Codeblock  within  the 
CLTU  may  contain  “Fill”  bits.  The  pattern  of  the  Fill  shall  consist  of  a  sequence  of 
alternating  “ones”  and  “zeros”  starting  with  a  “zero”. 

The  Coding  layer  may  require  the  introduction  of  these  fill  bits  in  the  encoding  process;  they 
are  not  removed  by  the  decoding  process.  Removal  of  fill  is  the  responsibility  of  the  layer 
above,  which  delimits  the  end  of  the  Input  Data  and  discards  extraneous  bits  (e.g.,  fill). 

Note  -  If  randomization  is  being  used,  any  fill  octets  that  were  added  to  the  last 
codeblock  of  the  CLTU  will  be  derandomized  even  if  they  were  not  randomized. 
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3.3.4  TC  CHANNEL  SERVICE  LOGIC 

The  TC  Channel  Service  Logic  at  the  receiving  end  is  presented  in  state  diagram  form 
(Figure  3-5).  To  support  the  state  diagrams,  a  list  of  “states”  and  “events”  is  given  in  Tables 
3-1  and  3-2.  There  are  three  states  and  four  events. 

Table  3-1:  TC  Channel  Service  States  (Receiving  End) 


State 

Number 

State 

Name 

State 

Definition 

SI 

INACTIVE 

The  telecommand  channel  is  INACTIVE  (i.e., 
“no  bit  lock  is  achieved”,  or,  alternatively, 

“no  bit  modulation  is  detected”. 

S2 

SEARCH 

The  incoming  bit  stream  is  searched,  bit  by 
bit,  for  the  Start  Sequence  pattern. 

S3 

DECODE 

TC  Codeblocks,  which  are  either  free  of 
error  or  which  can  be  corrected,  are 
received,  decoded,  and  derandomized  (if 
used),  and  their  contents  are  transferred 
to  the  layer  above. 

Table  3-2:  TC  Channel  Service  Events  (Receiving  End) 

Event 

Number 

Event 

Name 

Event 

Definition 

El 

CHANNEL 

ACTIVATION 

Bit  modulation  is  detected  and  bit  lock  is 
achieved:  telecommand  bit  stream  is  present. 

E2 

CHANNEL 

DEACTIVATION 

Bit  lock  is  lost  or  telecommand  signal  is  lost: 
telecommand  bit  stream  is  NOT  present. 

E3 

START 

SEQUENCE 

FOUND 

The  Start  Sequence  pattern  has  been  detected, 
signaling  the  beginning  of  the  first 
codeblock  of  the  CLTU. 

E4 

CODEBLOCK 

REJECTION 

The  decoder  has  indicated  uncorrected  errors 
in  a  codeblock.  No  data  from  this  codeblock 
are  transferred  to  the  layer  above. 
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E4 


Figure  3-5:  TC  Channel  Service  State  Diagram  (Receiving  End) 


3.3.5  TC  CODEBLOCK  DECODING  PROCEDURES  2 

Codeblocks  that  have  been  encoded  using  the  modified  BCH  code  described  in  3.3.2  may  be 
decoded  either  in  an  error-detecting  mode  or  in  an  error-correcting  mode,  depending  on 
mission  requirements.  When  the  error-detecting  mode  is  chosen,  one,  two  or  three  bits  in 
error  will  be  detected  within  the  codeblock  (not  counting  the  appended  Filler  Bit);  when  the 
error-correcting  mode  is  used,  one  bit  in  error  will  be  corrected  and  two  bits  in  error  will  be 
detected. 


2  The  description  to  follow  assumes  a  hard-limiting  detector  before  decoding,  but  a  soft- 
limiting  detector  is  not  intended  to  be  precluded. 
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4  PHYSICAL  LAYER:  STANDARD  DATA  STRUCTURES  AND 
PROCEDURES 

4.1  OVERVIEW  OF  THE  PHYSICAL  LAYER 

The  Physical  layer  provides  the  radio  frequency  data  path  which  connects  the  transmitting 
station  to  the  spacecraft,  and  its  associated  Physical  Layer  Operational  Procedures  (PLOPs), 
in  order  to  support  the  transmission  of  telecommand  data. 


4.2  STANDARD  DATA  STRUCTURES  WITHIN  THE  LAYER 

The  standard  data  structures  within  this  layer  are  the  Acquisition  Sequence,  CLTU,  and  the 
Idle  Sequence.  They  are  used  to  provide  synchronization  of  the  symbol  stream,  and  are 
described  below. 

4.2.1  ACQUISITION  SEQUENCE 

The  Acquisition  Sequence  is  a  data  structure  forming  a  preamble  which  provides  for  initial 
symbol  synchronization  within  the  incoming  stream  of  detected  symbols.  The  length  of  the 
Acquisition  Sequence  shall  be  selected  according  to  the  mission  telecommand  link 
performance  requirements  but  the  preferred  minimum  length  is  16  octets.  The  length  is  not 
required  to  be  an  integral  multiple  of  octets.  The  pattern  of  the  Acquisition  Sequence  shall  be 
alternating  “ones”  and  “zeros”,  starting  with  either  a  “one”  or  a  “zero”. 

4.2.2  CLTU 

The  CLTU  is  the  data  structure  (symbol  sequence)  furnished  from  the  layer  above,  and 
defined  in  3.2.2.  It  contains  the  data  symbols  that  are  to  be  transmitted  to  the  spacecraft. 
Each  codeblock  within  the  CLTU,  having  the  format  specified  in  3.2.1,  provides  at  least  2 
data  transitions  per  codeblock.  If  the  spacecraft  symbol  synchronization  design  necessitates 
more  frequent  transitions,  either  the  CLTU  as  delivered  to  the  physical  layer  must  have  been 
randomized  as  described  in  3.3.1  or  the  Physical  Layer  must  invoke  a  technique  (modulation 
type,  phase-coherent  data  and  subcarrier,  or  other)  to  guarantee  sufficiently  frequent 
transitions  for  adequate  symbol  synchronization. 

4.2.3  IDLE  SEQUENCE 

The  Idle  Sequence  is  the  data  structure  which  provides  for  maintenance  of  symbol 
synchronization  in  the  absence  of  CLTUs.  The  bit  pattern  is  a  sequence  of  alternating  “ones” 
and  “zeros’’.^  The  length  of  the  Idle  Sequence  is  an  unconstrained  number  of  bits. 


3  Previously,  the  idle  sequence  was  constrained  to  begin  with  a  “zero”  to  be  continuous  with 
the  tail  sequence.  Because  of  the  improved  performance  of  the  tail  sequence  in  this  issue, 
the  constraint  is  no  longer  necessary. 
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4.3  STANDARD  PROCEDURES  WITHIN  THE  LAYER 

Operations  within  the  Physical  layer  begin  with  the  activation  of  the  physical  telecommand 
charmel  by  invoking  the  radio  frequency  carrier  and  modulation  techniques.  These  techniques 
include  provision  of  any  required  conunand  link  subcarrier(s)  and  data  modulation  in  order  to 
establish  the  physical  connection  from  the  transmitting  station  to  the  proper  spacecraft 
hardware. 

4.3.1  CARRIER  MODULATION  MODES 

Carrier  Modulation  Modes  (CMMs)  consist  of  different  states  of  data  modulation  upon  the 
RF  carrier  which  creates  the  physical  telecommand  channel.  The  physical  methods  of 
modulating  the  carrier,  which  may  be  either  spread  spectrum  (e.g.,  TDRSS)  or  subcarrier 
(e.g.,  conventional  ground  station)  techniques,  are  described  in  Reference  [5].  The  Carrier 
Modulation  Modes  are  shown  in  Table  4-1. 

Table  4-1:  Carrier  Modulation  Modes 


Mode 

State 

CMM-1 

Unmodulated  CARRIER  only 

CMM-2 

CARRIER  modulated  with 
ACQUISITION  SEQUENCE 

CMM-3 

CARRIER  modulated  with 

TC  data  (e.g.,  CLTU) 

CMM-4 

CARRIER  modulated  with 

IDLE  SEQUENCE 

4.3.2  TELECOMMAND  SESSION 

During  a  Telecommand  Session,  a  series  of  CLTUs  is  transmitted  to  a  remote  spacecraft. 
The  session  begins  with  the  initial  application  of  the  RF  carrier  (CMM-1)  and  ends  with  the 
removal  of  the  carrier.  The  path  is  further  controlled  (activated  or  deactivated)  by  the 
selection  of  appropriate  Physical  Layer  Operations  Procedures  (PLOPs). 
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4.3.3  PHYSICAL  LAYER  OPERATIONS  PROCEDURES  (PLOPS) 

A  PLOP  consists  of  a  sequential  application  of  the  various  CMMs  in  order  to  activate  and 
deactivate  the  physical  telecommand  channel.  Two  procedures,  PLOP-1  and  PLOP-2,  are 
currently  defined.  The  selection  of  PLOPs  is  mission-specific. 

4.3.3.1  PLOP-1.  PLOP-1  is  a  procedure  for  individually  radiating  CLTUs,  whereby  the 
spacecraft  TC  decoder  is  always  forced  into  the  INACTIVE  state  (SI)  by  deactivating  the 
physical  telecommand  channel  after  the  end  of  transmission  of  each  CLTU  (or  CLTU 
followed  by  an  Idle  Sequence). 

PLOP-1  invokes  the  sequence  of  CMMs  shown  in  Figure  4-1.  Note  that  “unmodulated”  is 
defined  as  the  state  in  which  no  telecommand  modulation  is  present. 


BEGIN  COMMAND  SESSION 


END  COMMAND  SESSION 

Figure  4-1:  Sequence  of  CMMs  Comprising  PLOP-1 
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4.3.3.2  PLOP-2.  PLOP-2  is  a  procedure  whereby  the  physical  telecommand  channel  is 
not  deactivated  after  each  transmitted  CLTU.  The  termination  of  an  individual  CLTU  is 
provided  only  through  the  data  path,  using  the  CLTU  Tail  Sequenee  and,  optionally.  Idle 
Sequences.  This  places  the  decoder  in  the  SEARCH  state  (S2)  after  each  CLTU.  The 
decoder  is  forced  into  the  INACTIVE  state  (SI),  by  deactivating  the  physical  telecommand 
channel  only  at  the  end  of  transmission  of  a  series  of  CLTUs,  which  may  be  followed  by  an 
Idle  Sequence  or  not. 

It  should  be  noted  that  when  operating  with  PLOP-2,  it  is  recommended  to  systematically 
insert  a  minimum  Idle  Sequence  of  one  octet  between  each  CLTU  to  eliminate  the  small  but 
finite  possibility  of  synchronization  lockout.  Such  a  lockout  may  occur  if  the  start  pattern  of 
one  CLTU  is  not  detected  (leaving  the  decoder  in  SEARCH  state)  and  a  start  pattern  exists 
over  the  last  bits  of  the  last  frame  of  that  CLTU  and  the  first  bits  of  its  Tail  Sequence.  This 
creates  an  erroneous  but  temporary  CLTU  start  (DECODE  state),  causing  the  true  start  of  the 
following  CLTU  to  be  missed.  The  added  Idle  Sequence  prevents  this  from  happening. 

PLOP-2  invokes  the  sequence  of  CMMs  shown  in  Figure  4-2.  Note  that  “unmodulated”  is 
defined  as  the  state  in  which  no  telecommand  modulation  is  present. 
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BEGIN  COMMAND  SESSION 


END  COMMAND  SESSION 


Figure  4-2:  Sequence  of  CMMs  Comprising  PLOP-2 


CCSDS  20L0-B-2 


Page  4-5 


November  1995 


CCSDS  RECOMMENDATION  FOR  TELECOMMAND:  CHANNEL  SERVICE 


ANNEX A 

CHANNEL  SERVICE 
ACRONYMS  AND  TERMINOLOGY 


(THIS  ANNEX  IS  PART  OF  THE  RECOMMENDATION) 


Purpose: 

This  Annex  defines  the  key  acronyms  and  terms  which  are  used  throughout  this 
Recommendation  to  describe  activities  within  the  Channel  Service. 
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ACRONYMS 

BCH:  BOSE-CHAUDHURI-HOCQUENGHEM 

BTG;  BIT  TRANSITION  GENERATOR 

CCSDS;  CONSULTATIVE  COMMITTEE  FOR  SPACE  DATA  SYSTEMS 

CLTU:  COMMAND  LINK  TRANSMISSION  UNIT 

CMM:  CARRIER  MODULATION  MODE 

MSB :  MOST  SIGNIFICANT  BIT 

NRZ-M;  NON-RETURN-TO-ZERO-MARK 

PLOP:  PHYSICAL  LAYER  OPERATIONS  PROCEDURE 

TC:  TELECOMMAND 


TERMINOLOGY 

Terminology  for  the  overall  CCSDS  Telecommand  concept  is  summarized  in  Reference  [2]. 
Key  elements  of  Channel  Service  terminology,  as  used  in  this  document,  are  defined  in  this 
annex.  These  definitions  are  meant  to  be  used  by  the  reader  as  an  aid  to  understanding  the 
concept  of  Telecommand;  no  attempt  is  being  made  to  universally  define  these  terms. 
Definitions  which  may  be  found  in  a  standard  English  dictionary  have  been  omitted. 


ACQUISITION  SEQUENCE: 

A  specific  high  transition  density  bit  pattern  transmitted  to  permit  the  receiving  end  to 
acquire  symbol  synchronization. 


BIT  TRANSITION  GENERATOR: 

A  generator  that  produces  a  specific  random  sequence  of  255  bits  to  be  ORed  with  the  input 
TC  data  bits  to  increase  the  frequency  of  bit  transitions  (between  “1”  and  “0”).  No  additional 
bits  are  added  by  this  process. 


CARRIER  MODULATION  MODE: 

The  data  type  being  used  to  modulate  the  RF  carrier  or  subcarrier. 


CLEAN  DATA  BITS: 

TC  data  bits  which  have  been  decoded  and  are  outputted  from  the  Coding  layer. 


CODEBLOCK: 

A  fixed-length  data  entity  containing  information  and  check  bits  that  have  been  structured  by 
an  encoding  algorithm. 
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CODING  LAYER: 

That  layer  of  the  TC  Channel  Service  which  uses  a  prescribed  coding  technique  to  reliably 
transfer  information  bits  through  the  potentially  noisy  Physical  layer. 


COMMAND  LINK  TRANSMISSION  UNIT: 

A  Coding  layer  protocol  data  entity  which  is  used  to  synchronize  and  delimit  the  beginning 
of  a  continuum  of  bits  consisting  of  a  start  sequence  followed  by  an  integral  number  of 
codeblocks. 


COMMAND  SESSION: 

A  continuous  period  of  time  during  which  the  signal  path  is  established  for  the 
communications  channel. 


COMMAND  THRESHOLD: 

The  telecommand  channel  operating  point  at  which  a  deletion  rate  of  1  frame  per  1000 
frames  is  obtained. 


DECODER  (Hard  Decision): 

A  Coding  layer  algorithmic  process  which  utilizes  the  check  bits  contained  in  a  codeblock  for 
detecting  or  correcting  errors  in  the  information  bits.  The  check  bits  are  then  removed  before 
the  information  bits  are  outputted. 


DECODER  (Soft  Decision): 

A  Coding  layer  algorithmic  process  which  uses  quantization  of  the  detector  output  into  n 
levels  for  each  received  bit  to  decide  upon  the  most  likely  codeblock  and  to  estimate  the 
reliability  of  that  decision.  The  check  bits  are  then  removed  before  the  best-estimate 
information  bits  and  any  reliability  information  are  outputted. 


ENCODED  TC  DATA: 

The  TC  data  contained  in  a  codeblock. 
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ENCODER: 

As  used  in  this  document,  a  Coding  layer  algorithmic  process  which  adds  check  bits  to  a 
series  of  information  bits  to  create  a  codeblock. 


EVENT: 

As  used  in  this  document,  an  action  which  causes  the  TC  Channel  Service  to  change  states. 


FILL: 

Bits  appended  by  the  Coding  layer  to  the  Input  Data  to  enable  the  data  entity  to  exactly  fit  an 
integer  number  of  codeblocks.  These  fill  bits  ARE  transmitted  and  must  be  removed  by  the 
layer  above. 


IDLE  SEQUENCE: 

A  specific  high  transition  density  bit  pattern  transmitted  during  a  command  session  in  the 
absence  of  a  CLTU  to  maintain  symbol  synchronization  in  the  channel. 


INPUT  DATA: 

A  discrete  collection  of  data  bits  provided  at  the  input  to  the  Coding  layer  from  the  Data 
Routing  Service. 


OCTET: 

A  contiguous  string  of  8  bits;  an  8-bit  word. 


PHYSICAL  LAYER: 

The  lower  layer  of  the  TC  Channel  Service  which  provides  the  RF  channel.  At  the  sending 
end  it  provides  the  radio  frequency  and  modulation  techniques  required  to  create  and  operate 
the  channel.  At  the  receiving  end,  it  provides  the  reception,  demodulation,  and  symbol 
synchronization  for  the  channel. 
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PHYSICAL  LAYER  OPERATIONS  PROCEDURE: 

A  specific  procedure  of  the  Physical  layer  designed  to  activate  and  deactivate  the  physical 
telecommand  channel  by  invoking  RF  carrier  and  modulation  techniques. 


PROTOCOL: 

A  set  of  procedures,  supported  by  format  conventions,  that  define  the  orderly  exchange  of 
information  between  entities  within  a  given  layer  of  the  TC  System  or  between  layers. 


PSEUDO-RANDOMIZATION: 

Pseudo-Randomization,  herein  called  Randomization,  is  a  bandwidth-efficient  technique  of 
algorithmically  translating  the  data  bits  to  insure  frequent  bit  transitions  in  the 
communications  channel. 


RELIABLE: 

Meets  the  quality,  quantity,  continuity  and  completeness  criteria  which  are  specified  by  the 
Telecommand  System. 


START  SEQUENCE: 

A  specific  bit  pattern  at  the  beginning  of  a  CLTU  having  a  high  autocorrelation  function 
following  an  idle  or  acquisition  sequence  and  which:  a)  synchronizes  start  of  a  CLTU;  b) 
delimits  start  of  first  codeblock;  and  c)  resolves  the  sense  of  a  “1”  and  “0”  in  the  CLTU,  if 
necessary. 


SYMBOL: 

A  bit  in  an  encoded  data  stream. 


TAIL  SEQUENCE: 

A  specific  data  pattern  which  delimits  the  end  of  a  CLTU. 


TC  DATA: 

The  data  content  (after  decoding)  of  the  CLTU  which  is  outputted  to  the  Data  Routing 
Service  (layer  above)  and  which  may  include  fill. 
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TC  TRANSFER  FRAME: 

The  protocol  data  unit  of  the  Transfer  layer.  (See  Reference  [4],  Data  Routing  Service.) 


TELECOMMAND: 

A  generic  term  used  to  describe  the  process  of  telecommunicating  commands  to  the 
spacecraft. 


TELECOMMAND  CHANNEL  SERVICE: 

A  Telecommand  Service  which  provides  error-controlled  communications  across  the  space 
link. 


TELECOMMAND  DATA  ROUTING  SERVICE: 

A  Telecommand  Service  which  provides  error-controlled  message  communications  between 
remote  entities. 


VIRTUAL  FILL: 

Added  bits  which  are  NOT  transmitted,  but  their  presumption  in  the  encoding  process  must 
be  known  for  the  decoding  process  (i.e.,  the  decoder  must  know  the  codeblock  length.) 
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ANNEXE 

CHANNEL  SERVICE  SPECIFICATION 


(THIS  ANNEX  IS  PART  OF  THE  RECOMMENDATION) 


Purpose: 

This  Annex  provides  the  detailed  specification  for  the  service  provided  by  the  Coding  and 
Physical  layers  of  the  Telecommand  System. 
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B-1  OVERVIEW  OF  THE  LAYERS  WITHIN  THE  TELECOMMAND 
CHANNEL  SERVICE 

The  TC  Channel  Service  consists  of  two  layers:  the  Coding  layer  and  the  Physical  layer. 
Each  of  the  layers  provides  services  to  the  layer  above  (e.g.,  the  CCSDS  Transfer  layer, 
Reference  [4])  at  a  “sending  end”  (located  in  the  region  of  the  user)  and  at  a  “receiving  end” 
(located  in  space).  A  model  of  the  activities  within  the  Channel  Service  is  presented  in 
Figure  B-1. 


MODULATED  RADIO  WAVEFORMS 


NOTES:  (1 )  “CLEAN”  =  ERROR-FREE  WITHIN  THE  PERFORMANCE 
CAPABILITY  OF  THE  DECODER. 

(2)  “DIRTY”  =  SYMBOL  STREAM  WITH  POSSIBLE  ERRORS 
OR  SOFT  DECISIONS. 


Figure  B-1:  TC  Channel  Service  Model 
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Within  a  fully  implemented  CCSDS  Telecommand  system,  operation  of  the  Channel  Service 
begins  when  the  buffer  of  information  bits  corresponding  to  one  or  more  complete  TC 
Transfer  Frames  (plus  their  related  operational  control  information)  is  delivered  from  the 
Transfer  layer  to  the  sending  end  of  the  Coding  layer  for  radiation  through  the  physical 
telecommand  channel  to  the  spacecraft.  (See  Figure  B-2.) 

The  TC  Transfer  Frames  are  encoded  by  the  Coding  layer  into  short,  fixed  length  TC 
Codeblocks  which  provide  a  noise  immunity  capabihty  that  is  compatible  with  overall  TC 
Frame  rejection  and  undetected  error  requirements.  A  TC  Transfer  Frame  is  transmitted  as  a 
sequential  set  of  TC  Codeblocks,  with  the  entire  set  of  Codeblocks  being  encapsulated  by  the 
Coding  layer  within  a  “Command  Link  Transmission  Unit”  (CLTU)  data  structure:  a  CLTU 
may  contain  one  or  more  encoded  Transfer  Frames.  If  there  is  a  concern  that  the  CLTU  does 
not  have  adequate  symbol  transitions  to  maintain  symbol  synchronization,  then  the  Input  TC 
data  may  be  randomized  using  the  sequence  specified  by  the  BTG  in  3.3.1.  The  CLTU 
provides  the  data  interface  mechanism  for  passing  the  TC  Codeblocks  between  the  Coding 
layer  and  the  Physical  layer. 

To  activate  the  telecommand  channel  in  support  of  the  Coding  layer,  the  services  of  the 
sending  end  Physical  layer  are  invoked.  An  RF  carrier  data  path  is  first  established,  upon 
which  various  “Carrier  Modulation  Modes”  (CMMs)  may  be  established  to  support  data 
transfer.  By  selecting  an  appropriate  sequence  of  CMMs,  a  “Physical  Layer  Operations 
Procedure”  (PLOP)  is  formed  which  activates  and  deactivates  the  link  so  that  one  or  more 
CLTUs  may  be  transmitted  to  the  spacecraft. 

Upon  activation  of  the  channel  by  the  selected  PLOP,  modulated  radio  waveforms  are 
radiated  to  the  spacecraft.  The  receiving  end  of  the  Physical  layer  receives  this  waveform 
and  detects  a  stream  of  channel  symbols.  Control  information  which  indicates  the  readiness 
of  the  channel  is  passed  to  the  layer  above. 

The  spacecraft  telecommand  channel  decoder  within  the  receiving  end  of  the  Coding  layer 
awaits  this  symbol  stream  containing  an  Acquisition  sequence,  a  CLTU  Start  sequenee,  and 
the  set  of  sequential  TC  Codeblocks  which  carry  the  encoded  TC  Transfer  Frame  information 
bits.  The  Acquisition  sequence  provides  a  preamble  for  symbol  synchronization  purposes. 
The  CLTU  Start  sequence  marks  the  start  of  the  first  TC  Codeblock  (which  contains  the 
leading  bits  of  a  TC  Transfer  Frame).  TC  Codeblock  decoding  begins  after  the  CLTU  Start 
sequence  is  detected:  the  TC  Codeblocks  are  sequentially  decoded  to  reconstruct  the 
information  (Input  TC  data)  bits  which,  together  with  control  data,  are  passed  to  the  layer 
above  which  reassembles  the  TC  Transfer  Frame.  If  the  Input  TC  data  have  been 
randomized,  it  is  here  that  they  are  derandomized  before  being  passed  to  the  layer  above. 
After  transmission  of  all  TC  Codeblocks  contained  within  the  CLTU,  a  Tail  sequence  is 
transmitted  which  signals  the  end  of  the  CLTU,  and  may  be  followed  by  an  (optional)  Idle 
sequence  and  more  CLTUs.  Finally,  when  the  last  CLTU  has  been  transmitted  (followed  or 
not  by  an  Idle  sequence),  the  link  is  deactivated  by  the  PLOP. 
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INPUT  DATA 
from  layer  above 


TC  DATA 
to  layer  above 


^  ..  ,  String  of  derandomized  bits 

O^e  ^more^nt^uo^sfmm^. _ (wjth  p_ossible  Wl  bite). _ 

.  CODING  LAYER 


_ L _ 

FILL 

RANDOMIZE 

- - - 

\  If  used  for  the  mission  (optional) 

DERANDOMIZE 


If  necessary,  add  fill 
either  before  or  after 
Randomization  to 


FILL 

ir  number  of  codeblocks. 

DECODE 

BCH  ENCODE, 

CODEBLOCKS, 

add  parity  &  filler  bit 

delete  parity  and 

for  each  codeblock 

filler  bit 

Sequence  of  Codeblocks 


Decoded  (Randomized)  Input  Data 


Figure  B-2:  Sequence  of  Functions 

If  the  probability  of  erroneous  data  (as  measured  by  the  channel  decoder)  is  sufficiently  high, 
the  spacecraft  channel  decoder  will  enter  a  “Search  for  Start  Sequence”  condition  until  reset 
by  the  next  CLTU  Start  sequence  or  (optionally)  by  deactivation  of  the  link  by  the  PLOP. 
(See  4.3. 3.2.)  In  the  case  where  the  channel  decoder  is  in  the  “SEARCH”  state,  no  further 
data  bits  will  be  transferred  to  the  process  which  reassembles  and  accepts  the  TC  Transfer 
Frame  (the  layer  above)  until  the  decoder  returns  to  the  DECODE  state. 

Reporting  of  individual  decoded  TC  Codeblock  acceptance  by  telemetry  will  NOT  be 
performed,  unless  this  is  implemented  on  a  mission-specific  basis  for  the  purposes  of 
spacecraft  diagnosis  (e.g.,  via  engineering  telemetry  data).  Since  no  data  will  be  transferred 
to  the  spacecraft  TC  Transfer  Frame  reassembler  in  case  of  TC  Codeblock  error,  the 
operational  reporting  of  acceptance  is  performed  on  a  TC  Transfer  Frame  basis  via  the  Frame 
Acceptance  and  Reporting  Mechanism  (FARM)  as  described  in  Reference  [4]. 
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B-2  CODING  LAYER  SERVICE  SPECIFICATION 

The  basic  Quality  of  Service  of  the  Coding  layer  is  to  provide  a  reliable,  error-controlled  data 
channel  through  which  user  telecommand  data  bits  may  be  transferred. 

B-2.1  Coding  Layer:  Sending  End  Service  SpeciBcation 

(1)  INPUTS 

From  the  layer  above: 

(a)  “Input  Data”  from  the  Data  Routing  Service,  to  be  included  in  a  single 
CLTU. 

(b)  Control  instructions. 

From  the  layer  below; 

(c)  Status  of  the  physical  telecommand  channel  (i.e.,  report  from  the  Physical 
layer). 

(2)  OUTPUTS 

To  the  layer  above: 

(a)  Status  of  the  physical  telecommand  channel. 

To  the  layer  below: 

(b)  Command  Link  Transmission  Units  (CLTUs). 

(c)  Control  instructions. 

(3)  INTERNAL  FUNCTIONS 

(a)  Conditions  Input  TC  Data  by  randomizing  it  if  used  by  a  mission. 

(b)  Adds  fill  as  necessary  to  complete  the  last  codeblock  of  the  CLTU  (may  be 
done  before  or  after  randomizing). 

(c)  Encodes  the  Input  TC  Data  or  conditioned  Input  TC  Data  into  TC 
Codeblocks. 

(d)  Forms  the  TC  Codeblocks  into  a  CLTU  by  adding  the  Start  and  Tail 
Sequence. 
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B-2.2  Coding  Layer:  Receiving  End  Service  Specification 

(1)  INPUTS 

From  the  layer  below: 

(a)  Synchronized  detected  “dirty”  symbol  stream  (with  possible  errors  if  hard- 
decision  decoding  is  used). 

(b)  Symbol  clock  (if  required). 

(c)  Control  information  and  status  (e.g.,  physical  telecommand  channel  active 
or  inactive). 

(2)  OUTPUTS 

To  the  layer  above; 

(a)  “Clean”  decoded  and  derandomized  (if  used)  TC  data  from  each  codeblock 
which  have  passed  the  decoder  quality  check.  May  include  fill  from  last 
codeblock  of  CLTU. 

(b)  Decode  Status,  indicating  start,  continuity,  and  end  of  valid  TC  data. 

(c)  Control  information  describing  status  of  the  physical  telecommand  channel 
(e.g.,  RF  and  bit  synchronization). 

(3)  INTERNAL  FUNCTIONS 

(a)  Permits  the  resolution  of  the  sense  of  1  and  0  in  the  incoming  stream  of  dirty 
symbols,  if  not  already  provided  by  modulation  techniques  within  the  layer 
below. 

(b)  Detects  the  CLTU  Start  sequence  which  provides  decoder  synchronization 
for  the  first  codeblock;  subsequent  codeblocks  are  automatically 
synchronized  by  being  contiguous.  Signals  the  start  of  valid  TC  data. 

(c)  Within  the  capability  of  the  decoding  algorithm,  makes  an  estimate  to 
determine  if  an  error  has  probably  occurred  within  the  TC  Codeblock. 

(d)  Within  the  capability  of  the  decoding  algorithm,  optionally  makes  an 
estimate  of  the  correct  value  of  the  information  bits  if  errors  are  suspected  to 
have  occurred  within  the  group  of  symbols  that  correspond  to  one  TC 
Codeblock,  and  continues  decoding. 
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(e)  If  a  TC  Codeblock  is  encountered  which  is  sufficiently  likely  to  contain  a 
detected  or  uncorrectable  error,  declares  a  codeblock  error,  leaves  the 
DECODE  state,  enters  the  SEARCH  state  and  ceases  to  output  further  data. 
Signals  the  stop  of  valid  TC  data. 

(f)  If  the  Physical  layer  signals  loss  of  modulation,  leaves  the  DECODE  state, 
enters  the  INACTIVE  state,  ceases  to  output  further  data,  and  signals  the 
stop  of  valid  TC  data. 

(g)  If  the  mission  is  randomizing  its  TC  Data,  the  “Valid  TC  Data”  is 
derandomized  before  being  passed  to  the  layer  above. 

(h)  Informs  the  layer  above  of  status  of  the  Channel  Service. 


B-3  PHYSICAL  LAYER  SERVICE  SPECIFICATION 

The  basic  Quality  of  Service  of  the  Physical  layer  is  to  establish  a  physical  path  which 
connects  the  sending  end  of  the  Telecommand  System  to  the  receiving  end  in  space. 


B-3.1  Physical  Layer:  Sending  End  Service  Specification 

(1)  INPUTS 

From  the  layer  above: 

(a)  Buffers  of  bits  corresponding  to  a  CLTU. 

(b)  Control  information. 

(2)  OUTPUTS 

To  the  layer  above: 

(a)  Status  of  the  physical  telecommand  channel. 

To  the  receiving  end  of  the  layer: 

(b)  Modulated  radio  frequency  waveforms,  radiated  as  described  in 
Reference  [5]. 
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(3)  INTERNAL  FUNCTIONS 

(a)  Establishes  the  physical  radio  frequency  path  to  the  spacecraft  using  CMM- 1 . 

(b)  Radiates  a  buffer  of  data  bits  serially  according  to  the  PLOP  requested  by 
the  layer  above. 

B-3.2  Physical  Layer:  Receiving  End  Service  Specification 

(1)  INPUTS 

From  the  sending  end  of  the  layer: 

(a)  Modulated  radio  frequency  waveforms  which  have  been  radiated  by  a 
transmitting  station  as  described  and  specified  in  Reference  [5]. 

(2)  OUTPUTS 

To  the  layer  above: 

(a)  Synchronized  detected  “dirty”  symbol  stream. 

(b)  Symbol  clock  (if  required). 

(c)  Channel  Active  (modulated  carrier/subcarrier  present);  used  by  layer  above 
to  select  between  Inactive  and  Search  states,  to  validate  the  Decode  state  and 
in  some  cases  to  initiate  inter-layer  control  instructions. 

(d)  Status  of  the  RF  lock  and  bit  synchronization  processes. 

(3)  INTERNAL  FUNCTIONS 

(a)  Receives  and  detects  the  modulated  carrier/subcarrier. 

(b)  Performs  demodulation  and  symbol  synchronization. 

(c)  Determines  the  state  of  the  physical  telecommand  channel  (CHANNEL 
ACTIVE  or  CHANNEL  INACTIVE). 

(d)  Performs  symbol  detection  (hard  decisions  or  quantized,  soft  decisions). 

(e)  Informs  the  layer  above  of  status  of  the  Physical  layer. 
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B-4  CHANNEL  SERVICE  PERFORMANCE  SPECIFICATION 

The  performance  of  the  Channel  Service  is  specified  to  meet  the  requirements  defined  for  the 
layer  above.  In  the  case  where  the  layer  above  is  a  TC  Transfer  Frame,  the  performance 
specification  is  given  in  Reference  [4].  The  performance  provided  by  the  Channel  Service 
depends  on  the  performance  of  the  individual  elements  and  procedures  for  a  CLTU  defined  in 
Sections  3  and  4,  and  as  shown  in  Figure  3-4. 

Suggested  processing  alternatives  for  each  of  the  elements  of  a  CLTU  are  shown  in  Table  B-1 . 

Table  B-1:  Processing  of  CLTU  Elements 


Element 

Implementation 

Procedure 

Modulation  Start 

Acquisition  Sequence 

CLTU  “Start” 

Start  Sequence 

A:  0  error  in  start  seq. 

B:  0  or  1  error  in  start 
sequence 

CLTU  “Data  Unit” 

Codeblock 

A:  Triple  error  detection 

B:  1-bit  error  correction 

CLTU  “Finish” 

Tail  Sequence 

Idle  Sequence 

Codeblock  rejection 

Codeblock  rejection 

Modulation  End 

Physical  link 

Stop  modulation  (post-CLTU): 
A:  PLOP-1 

B:  PLOP-2 

The  overall  performance  for  different  combinations  of  the  above  strategies  (plus  variables 
such  as  CLTU  length)  is  given  in  Reference  [2].  Accordingly,  the  recommended  Channel 
Service  strategies  are  as  shown  in  Table  B-2. 


Table  B-2:  Recommended  Strategies 


CLTU 

CLTU 

Modulation 

Strategy 

Start 

Data  Unit 

End 

1 

A 

A 

AorB 

2 

B 

B 

AorB 
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